Skip to content

Fixed an issue where the game would freeze when the mouse moving over the window.#45

Closed
chansey97 wants to merge 2 commits intoivanperez-keera:developfrom
chansey97:develop
Closed

Fixed an issue where the game would freeze when the mouse moving over the window.#45
chansey97 wants to merge 2 commits intoivanperez-keera:developfrom
chansey97:develop

Conversation

@chansey97
Copy link
Copy Markdown

@chansey97 chansey97 commented Jan 17, 2024

See the new PR #46 and delete this PR if possible.


Phenomenon:

After executing spaceInvaders.exe, if you moving the mouse over the window, the game freezes!

Root cause:

When Yampa's sensing action takes window inputs, if the input is a HGL.MouseMove event, it will call mmFilter to consume all subsequent "redundant" HGL.MouseMove events. If there are several hundred HGL.MouseMove events, mmFilter will be recursively called several hundreds of times.

ThemmFilter further calls gwi win to take events, and gwi win calls HGL.getWindowTick win to yield some time slices to ensure that the thread actually receiving WM events gets a chance to work.

This leads to a problem:

Since HGL.getWindowTick win is a blocking operation (i.e. waiting for a tickRate time), if there are 100 subsequent HGL.MouseMove, it will wait for "100 x tickRate time", which is unacceptable. Moreover, during this waiting period, there might be further mouse move events generated!

This patch fixed the issue by placing HGL.getWindowTick win at the beginning of a frame, i.e. at the entry point of getTimeInput, rather than inside gwi win.

Phenomenon:

After executing spaceInvaders.exe,If you moving the mouse over the window, the game freezes!

Root cause:

When Yampa's sensing action takes window input, if the input is a `HGL.MouseMove` event, it calls `mmFilter` to consume all subsequent "redundant" `HGL.MouseMove` events. If there are several hundred `HGL.MouseMove` events, `mmFilter` will be recursively called several hundreds of times.

The`mmFilter` further  calls `gwi win` to take events, and `gwi win` calls `HGL.getWindowTick win` to yield the time slices to ensure that the thread acturally receiving WM events gets a chance to work.

This leads to a problem:

Since `HGL.getWindowTick win` is a blocking operation (i.e. waiting for a tickRate time), if there are 100 subsequent `HGL.MouseMove`, it will wait for "100 x tickRate time", which is unacceptable. Moreover, during this waiting period, there might be further mouse move events generated!

This patch fixed the issue by placing `HGL.getWindowTick win` at the beginning of a frame, i.e. at the entry point of `getTimeInput`, rather than inside `gwi win`.
@chansey97 chansey97 mentioned this pull request Jan 17, 2024
@chansey97 chansey97 closed this by deleting the head repository Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant